Komentowana treść: Wywiad z Trevorem Dickinsonem
11.04.2011 22:58
[#63]
Re: Wywiad z Trevorem Dickinsonem
@1989, post #61
W dobie wielopotokowych procesorów, (i wielo-innych-cudów) faktycznie czujesz się na siłach by napisać lepszą (szybszą) procedurę w asemblerze niż to, co wypluwa kompilator języka wysokiego poziomu, projektowany właśnie pod kątem maksymalnego wykorzystania tych featuresów, niejednokrotnie przy współpracy inżynierów projektujących dany CPU?
11.04.2011 23:39
[#64]
Re: Wywiad z Trevorem Dickinsonem
@tszczurek, post #63
Procesory od dawna sa wielopotokowe :). Kompilator nie rozumie lepiej algorytmu niz czlowiek, wiec zawsze lepiej i szybciej, tylko nie zawsze ma to sens np: po co optymalizowac i poswiecac czas programisty na procedure ktora nie jest newralgiczna. Wystarczy zerkac do profilera zeby znalezc takie miejsca i tylko takie ew. optymalizowac.
Natomiast pisanie nawet w jezyku wysokiego poziomu pod specyficzne "cuda" (np: SIMD) wymaga specyficznego programowania w tym jezyku, takze czasami latwiej/szybciej pisac w asemblerze niz zastanawiac sie za kazdym razem - zmiana wersji kompilatora lub inny kompilator... nad tym co kompilator zrobi lub nie zrobi, tak czy owak, znajomosc asemblera przydaje sie bardzo, chocby po to zeby ocenic..., bez specyficznego programowania instrukcje SIMD beda uzywane tak jak instrukcje FPU, czyli praktycznie to zadna optymalizacja, choc na wielu procesorach instrukcje SIMD wykonuja sie szybciej niz instrukcje FPU i dlatego warto wlaczyc taka opcje w kompilatorze, tylko to znow nie jest regula dla wszystkich procesorow...
Zasady optymalizowania pod procesory superskalarne nie sa az tak skomplikowane zeby nie dalo sie ich ogarnac, choc x86 jest wyjatkowo pokomplikowane... :). Zreszta, jezeli czlowiek-programista tego nie opanuje, to kompilator tym bardziej sobie z tym nie poradzi, bo kompilator tez jakis programista stworzyl
, automagicznie sie tu nic nie dzieje.
Ostatnia edycja: 12.04.11 00:18:06
Natomiast pisanie nawet w jezyku wysokiego poziomu pod specyficzne "cuda" (np: SIMD) wymaga specyficznego programowania w tym jezyku, takze czasami latwiej/szybciej pisac w asemblerze niz zastanawiac sie za kazdym razem - zmiana wersji kompilatora lub inny kompilator... nad tym co kompilator zrobi lub nie zrobi, tak czy owak, znajomosc asemblera przydaje sie bardzo, chocby po to zeby ocenic..., bez specyficznego programowania instrukcje SIMD beda uzywane tak jak instrukcje FPU, czyli praktycznie to zadna optymalizacja, choc na wielu procesorach instrukcje SIMD wykonuja sie szybciej niz instrukcje FPU i dlatego warto wlaczyc taka opcje w kompilatorze, tylko to znow nie jest regula dla wszystkich procesorow...
Zasady optymalizowania pod procesory superskalarne nie sa az tak skomplikowane zeby nie dalo sie ich ogarnac, choc x86 jest wyjatkowo pokomplikowane... :). Zreszta, jezeli czlowiek-programista tego nie opanuje, to kompilator tym bardziej sobie z tym nie poradzi, bo kompilator tez jakis programista stworzyl
, automagicznie sie tu nic nie dzieje.Ostatnia edycja: 12.04.11 00:18:06
12.04.2011 07:53
[#65]
Re: Wywiad z Trevorem Dickinsonem
@tszczurek, post #63
W dobie wielopotokowych procesorów, (i wielo-innych-cudów) faktycznie czujesz się na siłach by napisać lepszą (szybszą) procedurę w asemblerze
Nie wiem jak 1989, ale ja spokojnie. Mam przykład procedury używającej AltiVeca, która na Pegasosie 2 wykonuje się 20 razy szybciej (!) niż zwykły kod C robiący to samo. Oczywiście kod w C kompilowany jest z włączoną optymalizacją.
Nie wiem jak 1989, ale ja spokojnie. Mam przykład procedury używającej AltiVeca, która na Pegasosie 2 wykonuje się 20 razy szybciej (!) niż zwykły kod C robiący to samo. Oczywiście kod w C kompilowany jest z włączoną optymalizacją.
12.04.2011 20:22
[#69]
Re: Wywiad z Trevorem Dickinsonem
@1989, post #68
No niekoniecznie. Jeżeli się napisze "zwykły kod" w asmie bazując tylko na liście rozkazów procesora, to najczęściej będzie wolniejszy, niż dzieło kompilatora. Żeby konkurować z kompilatorem trzeba albo mistrzowsko opanować wewnętrzną budowę procesora (konkretnego modelu) i timingi instrukcji, co na przykład pokazuje kiero w swoich demach na 68060, albo wiedzieć o detalach algorytmu, których kompilator nie ogarnia, co m. in. wykorzystuję w algorytmach DSP korzystających z AltiVeca.
Ostatnia edycja: 12.04.11 20:27:01
Ostatnia edycja: 12.04.11 20:27:01
12.04.2011 21:28
[#70]
Re: Wywiad z Trevorem Dickinsonem
@G. Kraszewski, post #69
To sa przypadki. Jezeli ktos pisze nieoptymalnie w asemblerze, to mozna zalozyc, ze robi to rowniez w C/C++ i kompilator automagicznie tez tego nie naprawi, choc w przypadku skomplikowanej pokreconej architektury procesora np: x86 powyzej Pentium, lepiej glowy sobie nie zawracac asm, poza kilkoma specyficznymi przypadkami np: w/w SIMD. Dzisiaj jednak wiekszosc programistow stawia na przenoszalnosc kodu niz na jego optymalne dzialanie na scisle okreslonej architekturze, wychodzac z zalozenia, ze za chwile bedzie nowy szybszy procesor z nowymi instrukcjami allinone i nowym kompilatorem..., nie mozna jednak powiedziec, ze kompilator wypluwa optymalny kod i optymalizujac wstawkami w asm nie mozna osiagnac lepszego wyniku, na dzis czy najblizsza przyszlosc...
Taka dygresja:
W zasadzie dzis optymalizuje sie w asm glownie po to, zeby zmniejszyc wymagania na dzis - przyspieszyc w tym sensie, ten kod oczywiscie moze byc mniej optymalny na procesorach z przyszlosci (ktorych jeszcze nie ma) i mniej optymalny niz kod jaki wypluje kompilator z jeszcze bardziej odleglej przyszlosci.., jednak na procesorze z przyszlosci raczej nie bedzie dzialac gorzej niz dzis (to wazne!), wiec zarazem tracimy czas (na optymalizacje asm) i zyskujemy czas (na oczekiwanie kolejnego procesora, kompilatora etc..). W odleglej przyszlosci mozna ponownie podejsc do tematu optymalizacji w asm, jezeli program bedzie dalej rozwijany, a procesory rzeczywiscie ulegna istotnym modyfikacjom/ulepszeniom.
Ostatnia edycja: 12.04.11 21:51:55
Taka dygresja:
W zasadzie dzis optymalizuje sie w asm glownie po to, zeby zmniejszyc wymagania na dzis - przyspieszyc w tym sensie, ten kod oczywiscie moze byc mniej optymalny na procesorach z przyszlosci (ktorych jeszcze nie ma) i mniej optymalny niz kod jaki wypluje kompilator z jeszcze bardziej odleglej przyszlosci.., jednak na procesorze z przyszlosci raczej nie bedzie dzialac gorzej niz dzis (to wazne!), wiec zarazem tracimy czas (na optymalizacje asm) i zyskujemy czas (na oczekiwanie kolejnego procesora, kompilatora etc..). W odleglej przyszlosci mozna ponownie podejsc do tematu optymalizacji w asm, jezeli program bedzie dalej rozwijany, a procesory rzeczywiscie ulegna istotnym modyfikacjom/ulepszeniom.
Ostatnia edycja: 12.04.11 21:51:55